-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve error message when run_command_async
fails to find a command
#1831
Improve error message when run_command_async
fails to find a command
#1831
Conversation
CodSpeed Performance ReportMerging #1831 will not alter performanceComparing Summary
|
The implementationI agree that for errors exposed by a library a properly defined error enum is very important. I think that this error would actually benefit from using anyhow.
However by swapping to anyhow we can make this a little cleaner.
The testPersonally I wouldnt have written a test here, since the functionality is improving error messages in the test suite, not the application itself. I see no issue with comparing strings in the test here, since what we want to test is that the error message is written in a specific way. In fact the one issue with the test is that we arent properly comparing the strings.
and compare against that. In general though, your PR is looking good. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reapproving after changes.
Improves error output as defined in the #1829.
Here's a contrived sample output.
I would like you hear your thoughts on the testcase that I have added. The test is currently asserting on a string value instead of some custom error type. I generally do not like matching against string in my tests, but in this instance we are panicking anyways, so it is fine? or we are better off with a custom error type such as
RunCommandError